enhance binutils easyblock to ensure system search path is used for ld instead of the default one by setting $LIB_PATH in build step - #4204
Conversation
|
Test report by @Crivella Overview of tested easyconfigs (in order)
Build succeeded for 2 out of 2 (total: 6 mins 31 secs) (2 easyconfigs in total) |
|
Test report by @Crivella Overview of tested easyconfigs (in order)
Build succeeded for 14 out of 14 (total: 37 mins 10 secs) (14 easyconfigs in total) |
|
Test report by @cgross95 Overview of tested easyconfigs (in order)
Build succeeded for 2 out of 2 (total: 14 mins 28 secs) (2 easyconfigs in total) |
|
Going in, thanks @Crivella |
boegel
changed the title
binutils Ensure system search path is used for ld instead of the default onebinutils easyblock to ensure system search path is used for ld instead of the default one
| # this should 'harden' the resulting binutils to bootstrap GCC | ||
| # (no trouble when other libstdc++ is build etc) | ||
| lib_paths = self.determine_used_library_paths() | ||
| self.search_paths = lib_paths.copy() |
There was a problem hiding this comment.
@Crivella Since self.search_paths is used in sanity_check_step, can we already determine the list of library paths in the easyblock constructor instead?
That way, the sanity check commands will also be run when using --sanity-check-only...
There was a problem hiding this comment.
In particular to address the second point i am not sure this is possible.
We would need the dependencies to be available to be able to filter them out
boegel
changed the title
binutils easyblock to ensure system search path is used for ld instead of the default onebinutils easyblock to ensure system search path is used for ld instead of the default one by setting $LIB_PATH in build step
This bit was left unhandled, correct? |
4 participants
This should fix the problem observed in easybuilders/easybuild-easyconfigs#20375
Currently the
binutilsEBlock determines the system search path throughgcc -print-search-dirsand uses it to rpath builds in case of a system toolchain.The problem is that the
SEARCH_DIRSofldare not properly set to the system ones and the default (on eg Debian/Ubuntu) misses/usr/lib/x86_64-linux-gnuand/lib/x86_64-linux-gnu.For
nvidia-compilersthis causes failures when liking eglibclibdlandlibpthreadthroughlddirectly.This is not a problem in GCC based toolchains as gcc does its own logic to add this paths with
-Lstatementsnvc++innvidia-compilersinstead both adds-lc -ldl -lpthreadto every invocation and passes it directly toldcausing failures of the typeDetails
whit this PR the search dirs of ld will include the one given by the system compiler which should solve this issue
SEARCH_DIRS before PR
SEARCH_DIRS after PR
Potentially we might also want to exclude the non system libraries locations that are now detected (eg
zlibandflexwhich are present due to being loaded at build time)